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Abstract — In this paper, a high-level comparison of both 
SOAP (Simple Object Access Protocol) and REST (Repre- 
sentational State Transfer) is made. These are the two main 
approaches for interfacing to the web with web services. 
Both approaches are different and present some advantages 
and disadvantages for interfacing to web services: SOAP is 
conceptually more difficult (has a steeper learning curve) and 
more "heavy-weight" than REST, although it lacks of standards 
support for security. In order to test their eficiency (in time), 
two experiments have been performed using both technologies: 
a client-server model implementation and a master-slave based 
genetic algorithm (GA). The results obtained show clear dif- 
ferences in time between SOAP and REST implementations. 
Although both techniques are suitable for developing parallel 
systems, SOAP is heavier than REST, mainly due to the 
verbosity of SOAP communications (XML increases the time 
taken to parse the messages). 

I. Introduction 

Service Oriented Architecture (SOA) |T1 is a paradigm for 
organizing and utilizing distributed computational resources, 
called services. Using this paradigm, the service providers 
publish the descriptions (or interfaces) of the services they 
offer in a service registry, so the service requesters can 
discover them and bind to the correspondant service provider 
The Web Services are the key point of integration for differ- 
ent applications belonging to different platforms, languages, 
systems since they are based in a set of standards that make 
them independent of the underlaying technologies used for 
providing them. 

Although there are several technologies for developing 
web services (SOAP, REST or XMLRPC among others 
121, [Ul), nowadays the main approaches are SOAP (Simple 
Object Access Protocol) iU, JS] and REST (Representational 
State Transfer) f6l. Both implementacions are suitable for de- 
signing Web Services, however, it is important to understand 
the pros and cons of each one. 

SOAP is the traditional, standards-based approach, but the 
majority of the web services with public API offer REST 
interfaces, while some of them offer both REST and SOAP 
and very few offer just SOAP. All of the major Web Services 
providers use REST: Twitter, Yahoo's, Flickr, del.icio.us, 
pubsub, bloglines, technorati, and several others. Both eBay 
and Amazon have Web Services for both REST and SOAP. 

On the other hand, SOAP Web Services are used in lots of 
enterprise software as well; for example, Google implements 
their Web Services using SOAP, with the exception of 
Blogger, which uses XML-RPC, an early and simpler pre- 
standard of SOAP. 
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The philosophies of SOAP and RESTful Web Services are 
very different. Strictly, SOAP is a protocol for distributed 
computing, whereas REST adheres much more closely to a 
web-based design. SOAP requires a greater implementation 
and understanding effort of the client side to difference of 
REST based APIs, that focus these efforts on the server side. 
Table H] shows the main strengths and weaknesses for both 
SOAP and REST. 

It is important to note that one of the advantages of SOAP 
is the use of the "generic" transport. While REST today uses 
HTTP/HTTPS, SOAP can use almost any transport to send 
the request. However, one perceived disadvantage is the use 
of XML because of its verbosity, and the time necessary to 
parse it. 

In this way, in order to determine the efficiency of these 
two interfacing approaches, we have performed two exper- 
iments in which both a SOAP and REST implementations 
are evaluated: 

• Experiment 1: a client-server model is implemented, 
in which the server process runs on a machine and the 
client processes send and receive text strings. 

• Experiment 2: a master-slave based GA is imple- 
mented, running on the master process the GA and the 
fitness evaluation on the slave processes. 

This work continues with our previous research in ser- 
vice oriented algorithms, as previously stated in [7], where 
a service-oriented platform was presented, or [|8], where 
studies about P2P distributed evolutionary algorithms were 
performed. 

This paper is structured as follows: In sections HIl and Hill a 
comprehensive description of SOAP and REST technologies 
are provided, respectively. Section |IV] describes the experi- 
ments. In concrete, the client-server and master-slave models 
implemented for testing are described, so the experimental 
configuration, the methodology considered in the study ; 
finally, the results obtained are shown. Last section (Section 
IVT l. throws some conclusions and presents the proposed 
future work. 

II. SOAP: Simple Object Access Protocol 

SOAP is a standard protocol proposed by the W3C (H, 
|5|) to interface Web Services, and that extends the remote 
procedure call (XML-RPC). Thus, SOAP can be considered 
as an evolution of XML-RPC protocol, much more complete 
and mature, that allows to perform remote procedure calls to 
distributed routines (services) based on an XML interface 
as interfacing language. Thus, SOAP clients can access to 
objects and metods that are residing in remote servers, using 
an standard mechanism that makes transparent the details of 
implementacion, such us the programming language of the 



TABLE I 

Strengths and weaknesses for both SOAP (above) and REST (below). 



SOAP 


Strengths (pros) 


Weaknesses (cons) 


+ Handle distributed computing environments 
+ Built-in error handling 
+ Extensibility 

+ Language, platform, and transport agnostic 

+ Prevailing standard for web services 

+ Support from other standai'ds (WSDL, WS-*) 


- More verbose 

- Harder to develop, requires tools 

- Conceptually more difficult, more 
"heavy-weight" than REST 


REST 


Strengths (pros) 


Weaknesses (cons) 


+ Language and platform agnostic 

+ Much simpler to develop than SOAP 

+ Small learning curve, less reliance on tools 

+ Concise, no need for additional messaging layer 

+ Closer in design and philosophy to the Web 


- Assumes a point-to-point communication model 

- Not usable for distributed computing environment 

- Lack of standards support for security, etc. 

- Tied to the HTTP transport model 



routines, the operating system or the platform used by the 
provider of the service. At the moment, there exist complete 
implementations of SOAP for Perl, Java, Python, C-n- and 
other languages In opposite to other remote procedure 
call methods, such as RMI (remote method invocation, used 
by the Java language) or XML-RPC, SOAP has two main 
advantages: it can be used with any programming language, 
and it can use any type of transport (HTTP, SHTTP, TCP, 
SMTP, POP and other protocols). 

SOAP sends and receives messages using XML ifTOl . 
ifTTl . fT2], wrapped HTTP-in headings. The interfaces of 
the metods that can be accessed using SOAP services are 
specified by a Web Services Description Language (WSDL) 
pTl, [TT|. The WSDL of an Web Service consists in an XML 
description of its interface, i.e., it is a file that describes the 
name of the methods, the parameters and type of data, the 
type of response that the Web Service may return, etc. Using 
an WSDL file, that it is based on a neutral language such as 
XML, the service can be specified for different languages, 
so that a Java client can access a Perl server 

In this way, SOAP constitutes a high level protocol, 
making easy the task of distributing objects among different 
servers, and avoiding the difficulties derived of defining the 
message formats, nor the explicit call to remote servers. 

III. REST: Representational State Transfer 

After some years, Internet architects have found an al- 
ternative method for building web services in the form of 
Representational State Transfer (REST) [6 1 . 

REST is a style of software architecture for distributed 
hypermedia systems such as the World Wide Web. The term 
Representational State Transfer was introduced and defined 
in 2000 by Roy Fielding in his doctoral dissertation lITSl . 
pFl. Fielding is one of the principal authors of the Hypertext 
Transfer Protocol (HTTP) specification versions LO and LI 

ini, m. 



REST-style architectures consist of clients and servers. 
Clients initiate requests to servers; servers process requests 
and return appropriate responses. Requests and responses 
are built around the transfer of representations of resources. 
A resource can be essentially any coherent and meaningful 
concept that may be addressed. 

Although REST was initially described in the context of 
HTTP, is not limited to that protocol. RESTful architectures 
can be based on other Application Layer protocols if they al- 
ready provide a rich and uniform vocabulary for applications 
based on the transfer of meaningful representational state. 
RESTful applications maximize the use of the pre-existing, 
well-defined interface and other built-in capabilities provided 
by the chosen network protocol, and minimize the addition 
of new application-specific features on top of it. 

In a REST environment, clients are not concerned with 
data storage, which remains internal to each server, so that 
the portability of client code is improved. Servers are not 
concerned with the user interface or user state, so that 
servers can be simpler and more scalable. Servers and clients 
may also be replaced and developed independently, as long 
as the interface is not altered. Finally, servers are able to 
temporarily extend or customize the functionality of a client 
by transferring logic to it that it can execute. 

IV. SOAP vs REST: COMPARING Efficiency 

In this paper we carry out two experiments to compare 
two parallel models implemented using SOAP and REST 
technologies in Perl language (due to the familiarity of the 
authors with this language [19\, lEH). 

The SOAP model was implemented using the 
SOAP::Liti] [22] module, while the REST implementation 
was carried out using the Perl DanceiH module [I23l, ll24l . 
for their stability. In addition, servers developed using these 

' http://www.soaplite.com 
^http://perldancer.org 



modules are easy to implement and deployed using the 
computer infrastructure valilable to us in our department. 

The Experiment 1 consisted in the implementacion of a 
client-server model. In this case, the server process runs on 
a machine that attends client requests, involving different 
lengths of text strings. The experiment 2 implements a 
master-slave based GA. In this case, a master process runs 
the GA, while different slave processes evaluate the fitness 
function. 

A. Proof of Concept: Client-Server Efficiency Comparation 

A classic client-server model is implemented in which 
clients can send and receive a text string. Different string 
lengths (100 and 1000 chars) have been configured in order 
to probe with different loads. In this way, we have tried to 
determine how the string length (the amount of data) affects 
the running time (due to communications). 

Figures [T] and |2] show the Perl source code of the client- 
server SOAP and REST implementations. 

The implementacion of this experiment was conducted 
running the server process on a Ubuntu/Linux machine, while 
the clients were run on a Windows 7 with the CygwiiJl 
environment. 

As string lengths, values of 100 and 1000 characters have 
been used, in order to test whether the communications time 
depends on the amount of information sent. In both cases, 
the experiment was repeated for 50 times measuring the time 
spent using "gettimeofday" function (in order to achieve a 
good precision). 

As shown in Table HH the SOAP version takes more time 
to complete the communications than the REST implemen- 
tation. 

TABLE II 

Results obtained on the first experiment (client-server 
implementations). soap version takes a slightly higher time, 
although differences between sending a 100 chars string and a 1000 
chars string are smaller. 





sending 100 chars 


sending 1000 chars 


SOAP 


5.64 ± 0.17 


5.83 ± 0.17 


REST 


2.56 ± 0.10 


3.45 ± 0.10 



There are many ways to implement a distributed genetic al- 
gorithm, one of which is the global paralelization (farming), 
in which, as Fogarty and Huang propose [,25] , Abramson and 
Abela 1261 . or Hauser and Manner lIZTl . individual evaluation 
and/or genetic operator application are parallelized. A master 
processor supervises the population and select individuals to 
mate; then slave processors receive the individuals to evaluate 
them and to apply genetic operators. 

An ideal client-server implementation of a distributed 
evolutionary algorithm could be a server process with several 
threads. Each thread would include a population, and would 
communicate with other threads through the shared code 
among them. Each thread would use an own tail of indi- 
viduals to send to other threads. Each thread would evaluate 
its individuals in different remote computers, carrying out 
the communication using a REST server. 

However, as we cannot use a threaded version of the 
Perl modules, our implementation will focus on the fitness 
function evaluation. 

Thus, the simplest way of task distribution along this 
model is to evaluate the individual fitness function on the 
clients and to do the other steps on a master process (as 
shown in Figure [3]i; this scheme is usually called farming. 
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Fig. 3 

Schema of the master-slave based GA implemented in the 

SECOND EXPERIMENT. THE MASTER PROCESS RUNS THE GA AND THE 
SLAVE PROCESSES EVALUATE THE FITNESS FUNCTION. 



SOAP version takes a slightly higher time, although differ- 
ences between sending a 100 chars string and a 1000 chars 
string are smaller REST implementation is faster due to the 
fact that no extra XML information is sent (that reduces the 
time taken to parse the messages). 

B. Master-Slave based GA Implementation 

In the Experiment 2, we have parallelized a GA following 
a master-slave model. We do not intend to innovate in terms 
of the parallel model, but in the implementation (because 
implementation matters ET\ ). 

http://www.cygwin.com 



The evolutionary algorithm has been implemented 
using the Algorithm: :Evolutionary (A::E) library llT9l . 
[28|. Version 0.76.2 is used in this work, available at 
http://opeal.sourceforge.net under GPL Hcense. 

In this experiment, the fitness function is devoted to 
optimize the function given by equation [T] which is plotted 
in Figure m Our aim is to find the optimum (/(0,0) — 1) 
with an accuracy of 10^®. 



use SOAP::Transport::HTTP; 
my $daemon = 

SOAP::Transport::HTTP::Daemon 
-> new (LocalPort => 80) 
-> dispatch_to('Demo'); 

$daemon->handle; 

package Demo; 
our $src=""; 
sub push { 

my ($class, $cad) = @_; 

$self->src = $cad; 

return "ok"; 

}; 

sub pop { 

my $tmp = $self->src; 
$self->src = " "; 
return $tmp; 

}; 



use Time::HiRes qw( gettimeofday tvJnterval); 
use SOAP::Lite; 
my $i=0; 

my $tmpjt = [gettimeofday ()]; 
for ($i=0; $i<100 ; $i++) { 

my $cad="0 1234567890 ... 01234567890"; 

print SOAP::Lite 



-> uri('http://www.soaplite.com/Demo ) 
-> proxy('http://vaio/l ) 
-> push($cad) -> result; 
print SOAP::Lite 



-> uri('http://www.soaplite.com/Demo ) 



-> proxy('http://vaio7') 
-> popO -> result; 

}; 

print "TIME: ", tv jnterval( $tmpjt ); 



Fig. 1 

SOAP PROGRAMMING EXAMPLE: SERVER (LEFT) AND CLIENT (RIGHT). THE STRING $CAD VALUE VARIES FROM 100 TO 1000 CHARS IN ORDER TO 

CONFIGURE DIFFERENT LOADS. 



use Dancer; 

my $src = ""; 

get '/pop/' => sub { 

my $tmp = $src; 

$src = " "; 

return $tmp; 

}; 

get '/push/:cad' => sub { 
my ($class, $cad) = @_; 
$src = $cad; 
return "ok"; 

}; 

Dancer->dance; 



use Time::HiRes qw( gettimeofday tvjnterval); 
use LWP; 

my $nav = new LWP::UserAgent; 
$nav- > agentC'RESTzilla") ; 
my $i=0; 

my $tmpJt = [gettimeofdayO]; 
for ($i=0; $i<100 ; $i++) { 

my $cad="01234567890 ... 01234567890"; 
my $rpush = new HTTP::Request GET 

=> 1http://127.0.0.1:3000/push4 ."$cad": 
my $upush = $nav->request($rpush); 
my $rpop = new HTTP:: Request GET 

=> 'h ttp://127.0.0 .1:3000/pop/'; 
my $upop = $nav->request($rpop); 

}; 

print "TIME: ", tvJnterval( $tmp it ); 



Fig. 2 

REST PROGRAMMING EXAMPLE: SERVER (LEFT) AND CLIENT (RIGHT). THE STRING $CAD VALUE VARIES FROM 100 TO 1000 CHARS IN ORDER TO 

CONFIGURE DIFFERENT LOADS. 



GA individuals are represented using bitstrings (data type mutation (A::E::Op::Mutation) and a two points crossover 
A::E::lndividual::bitstring). As genetic operators, a bitflip (A::E::Op::Crossover) are used. 



V. Conclusions 




Fig. 4 



Fitness function representation (given by equation[TJ. The 

OPTIMUM OF this FUNCTION IS /(O, 0) = 1. 



Remainder GA parameter values are set as follows (default 
values are used, since we do not intend to find the optimal 
ones, but to prove feasibility of the implementation, and carry 
out a comparison): 

< Population size = 50 
« Generations = 20 
. Mutation rate = 20% 
> Crossover rate = 80% 
« Selection rate = 40% 

The full source code (servers, GA and evaluators) and 
experiment data are available under GPL at: 
^ttp://atc.ugr.es/pedro/RESTvsSOAP.tgz 

As seen in Table |III1 the REST implementation is faster, 
due to the SOAP verbosity and time taken to decode the 
XML messages. 

TABLE III 

Results obtained on the second experiment (master-slave 
implementations). both implementations obtain good results using 
even a small number of generations and population size. as far as the 
running time is concerned, rest implementation is faster in both 
configurations (10 gen. / 10 indiv. and 20 gen. / 50 indiv.). 





10 generations 
10 individuals 


20 generations 
50 individuals 


SOAP 


accuracy 
time (sec.) 


0.997942 ± 0.000762 
3.79 ± 0.42 


0.999867 ± 0.000101 
31.03 ± 1.89 


REST 


accuracy 
time (sec.) 


0.996092 ± 0.004081 
2.06 ± 0.08 


0.999976 ± 0.000003 
15.05 ±1.17 



Both implementations obtain good results in terms of accu- 
racy (both find the optimum with an accuracy of 10^^) using 
even a small number of generations and population size. As 
far as the running time is concerned, REST implementation 
is faster for both load configurations. As in the client-server 
experiment, it might be due to the XML verboseness of 
SOAP communications (that increases the time taken to parse 
the messages). 



As reported in the experiments provided, both techniques 
are suitable for developing parallel systems. However, SOAP 
is heavier than REST, due to the verbosity of SOAP com- 
munications (XML increases the time taken to parse the 
messages). 

On another hand, REST technology could not be used to 
implement a distributed GA following the island model as 
it does not support asynchronous processing and invocation, 
while SOAP does support it. 

We can conclude that each technology approach has their 
uses. Moreover, they both have pros and cons. However we 
can devise some applications/situations where one of them 
might work better than the other: 

• REST is more suitable if... 

- bandwidth and resources are limited 

- stateless CRUD (Create, Read, Update, and Delete) 
operations are needed (operation does not need to 
be continued) 

- the information can be cached because of the totally 
stateless operation of the REST approach 

• SOAP is a good solution if... 

- the application needs asynchronous processing and 
invocation 

- the application needs a guaranteed level of reUabil- 
ity and security 

- both sides (provider and consumer) have to agree 
on the exchange format (rigid specifications) 

- the application needs contextual information and 
conversational state management (stateful opera- 
tions) 

From these REST implementations, several paths for im- 
provement are devised: changing the models so that more 
computation is moved to the clients, leaving the server 
as just a hub for information interchange among clients; 
that information interchange will have to be reduced to the 
minimum. That will make this model closer to the island 
model, with just the migration policies regulated by the 
server That way, the server bottleneck is almost eliminated. 

As future research, it could be of interest adding support 
for SOAP and REST to existing distributed evolutionary 
algorithm libraries, such as JEO [291, EO [30], and libraries 
in other languages, in order to allow the implementation 
of multi-language evolutionary algorithms. In these exper- 
iments, Perl language has been used. It could be interesting 
to test these technologies using other programming languages 
and libraries (i.e. Java). 
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